home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 566 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.1 KB  |  112 lines
  1. Path: gramercy.ios.com!lalit
  2. From: lalit@gramercy.ios.com (lalit gidwani)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Exceptions vs. assertions
  5. Date: 5 Jan 1996 02:00:55 GMT
  6. Organization: Internet Online Services
  7. Message-ID: <4ci0on$77p@news2.ios.com>
  8. References: <4cbfac$kst@dawn.mmm.com> <DKMJsE.LH5@falcon.daytonoh.attgis.com>
  9. NNTP-Posting-Host: gramercy.ios.com
  10. X-Newsreader: TIN [version 1.2 PL2]
  11.  
  12. Dick Menninger (Dick.Menninger@DaytonOH.ATTGIS.COM) wrote:
  13.  
  14. : > ==========Kevin J Hopps, 1/2/96==========
  15. :  
  16. : > Chris Page (page@tiac.net) wrote:
  17. : > > lalit@gramercy.ios.com (lalit gidwani) wrote:
  18.  
  19. : [stuff deleted]
  20.  
  21. : > > is this: If I expect a condition to occur during normal operation of
  22. : > > my program, then I do not use exceptions for it.  I use exceptions,
  23. : > > only for exceptionally conditions, which I do not expect to
  24. : occur, but
  25. : > > I have to anticipate.
  26. : > 
  27. : > This is a good approach.  The issue of whether to throw exceptions or
  28. : > return status values is best decided by how likely the failure is than
  29. : > by how catastrophic it is.  (Besides, the caller of a function knows
  30. : > better than the function itself how costly the failure is.)
  31.  
  32. : Exceptions are a control paradigm.  Would you choose any
  33. : other control paradigm based on frequency or importance
  34. : of the issue being modeled (programmed)? It would seem that
  35. : the choice should be based on trying for the best expression
  36. : of the problem.  I suspect there are problems to be modeled
  37. : where they are best expressed with an exception used for
  38. : the success path.  In fact, that is one of the reasons I push
  39. : for multiple simultaneous exceptions being valid in the language
  40. : (so you can have an error exception while returning a success
  41. : exception).  Such problems are likely to be related to problems
  42. : where multi-level breaks (usually simulated by a goto) are very
  43. : helpful in clarifying the expression of the model.  For such
  44. : problems, the solution may perform better with an exception
  45. : for success.
  46.  
  47. : Good Day
  48. : Dick
  49. : Dick.Menninger@DaytonOH.ATTGIS.COM
  50.  
  51.  
  52. Thanks Dick!
  53.  
  54.     I have a few simple lines of code. Do you think
  55. the C++ exception mechanism has been properly used here:
  56.  
  57. class SaveError;    // exception class
  58.  
  59. void GetDataFromScreen() throw();
  60. void SaveDataInDatabase() throw( SaveError );
  61. void SaveCurrentInvoice() throw( SaveError );
  62.  
  63.  
  64. int main( int argc, char **argv )
  65. {
  66.     /*****************
  67.  
  68.         Send the selected invoice to screen and
  69.         wait for user to say he wants to
  70.         save the current invoice.
  71.  
  72.     ******************/
  73.  
  74.     try
  75.     {
  76.         SaveCurrentIncoice();
  77.     }
  78.     catch( SaveError se )
  79.     {
  80.         // send error message to the user
  81.     }
  82.  
  83. }// main
  84.  
  85. void SaveCurrentInvoice() throw ( SaveError )
  86. {
  87.     GetDataFromScreen() // always succeeds in this system
  88.     try 
  89.     {
  90.         SaveDataToDatabase();
  91.     }
  92.     catch( SaveError err )
  93.     {
  94.         throw err;
  95.     }
  96. }
  97.  
  98.  
  99. If this code seems OK, I have two comments:
  100.  
  101. 1. It seems to increase the amount of code. However, it seems
  102.    that the exception-handling would reduce code if there
  103.    where many lines of code in a try block that could throw
  104.    exceptions.
  105. 2. This seems to be an issue that needs to be thought out well.
  106.  
  107. P.S. The syntax may not be absolutely correct.
  108.  
  109.  
  110. Thanx
  111. LG
  112.